CloudWatchアラームとSNSでEC2インスタンスのステータスチェックをしてみよう

こんにちは！AWS事業本部コンサルティング部のたかくに（@takakuni_）です。

今回は、CloudWatchアラームとSNSを使用してEC2インスタンスのステータスチェックをしてみようと思います。

今回チェックを行うメトリクスは、以下の通りです。

• StatusCheckFailed_System
• StatusCheckFailed_Instance

StatusCheckFailed_System / Instanceの違い

メトリクス名や用途が似ていますが、エラーの起因箇所が異なります。

ステータスチェックメトリクス

ステータスチェックのタイプ

StatusCheckFailed_System

システムステータスをチェックするメトリクスです。

システムステータスとは、AWS側の責任範囲で発生している問題が検出されます。

StatusCheckFailed_Instance

インスタンスステータスをチェックするメトリクスです。

インスタンスステータスとは、ユーザー側の責任範囲で発生している問題が検出されます。

しかし、前述の「システムステータス」が問題で、「インスタンスステータス」が失敗する場合もあります。

そのため、一概に「ユーザー側の問題」とは言い切れず注意が必要です。

（参考）StatusCheckFailedメトリクスの活用

上記の「StatusCheckFailed_System / Instance」をまとめたメトリクスです。

「StatusCheckFailed」メトリクスの活用は、以下のメリットデメリットがあります。

メリット

• アラーム数が少なくなる（インスタンス別にアラームを設定している場合などは効果が大きい）

デメリット

• システムステータスとインスタンスステータスのどちらで検知されたのか判別しづらい

上記のようなメリット / デメリットがあるため、要件に沿った設計が重要となります。

Auto Recoveryを設定する際は、アラートメトリクスとして「StatusCheckFailed」ではなく「StatusCheckFailed_System」を使用する必要があります。

手順

SNSトピックの作成

まずは、通知先であるSNSトピックを作成します。

SNS管理コンソールから、「トピックを作成」をクリックし、「トピックの作成」画面へ遷移します。

「名前」と「表示名」の違い

SNSトピックでは、「名前」と「表示名」の設定値があります。

「名前」は、設定変更で使用する名前で、「表示名」は、メールで飛んでくる送信元の名前です。

わかりづらいので画像で補足します。

「名前」は、ARNで使用される値となります。

そのため、マネジメントコンソールやAWS CLIで参照する値は、「名前」となります。

以下、「サブスクリプションの作成」でトピックを参照した場合、「名前」が表示されています。

AWS CLIでも「サブスクリプションの作成」では、トピックARN（名前）が使用されます。

トピックへのサブスクライブ

$ aws sns subscribe --topic-arn arn:aws:sns:us-west-2:123456789012:my-topic --protocol email --notification-endpoint saanvi@example.com

対して「表示名」は、メールで使用する送信元の名前です。

以下、サブスクリプション作成時のメールです。送信元は「表示名」で受信しています。

サブスクリプションの作成

順番が前後しますが、SNSトピックから配信するサブスクリプションを作成しました。

今回は、メールアドレス宛に通知を行うため「Eメール」を選択します。

CloudWatch アラームの作成

StatusCheckFailed_System / StatusCheckFailed_Instanceは、インスタンス別でアラームを設定可能なメトリクスです。

今回は、テスト用のEC2インスタンスを対象にアラームを設定します。

CloudWatch管理コンソールから、「すべてのアラーム」、「アラームの作成」でアラームの作成画面へ遷移します。

「メトリクスの選択」から、「EC2」の名前空間を選択します。

取得したいメトリクスを、コンソールから選びます。「メトリクスの選択」をクリックします。

注意点として、マネジメントコンソールからアラームを設定する場合、選択可能なメトリクスはCloudWatchで確認できるメトリクスに限ります。

EC2インスタンス初回起動後は、CloudWatchのメトリクス反映（確認可否）までにラグがあります。

そのため、アラームを設定する場合は、インスタンス起動後5分から10分ほど待ってから登録をお勧めします。

実際に、前後のスクリーンショットを確認するとメトリクス数は、「175」から「192」に変わっています。

今回の検証では、メトリクスが全て反映されるまで5-6分経過しました。

取得するメトリクスの収集間隔を設定します。

以下の例だと、「5分間の最大値」をアラームの判定条件としています。

次に、条件を設定していきます。

しきい値で、「0よりも大きい」を設定することで、1(エラー)がカウントされた時にアラートを出すように設定します。

また、「アラームを実行するデータポイント」では「過去何回までさかのぼり判定するか」を設定します。

以下の例だと、「 1　/　3 」で設定しているため、エラーが解消されて0が発行されるようになってからも、最低2回はアラートで判定されます。

「通知」設定では、「どの状態になったときにアラームをトリガーするか」を設定できます。

今回は、「アラーム状態」で設定します。「SNSトピックの作成」で作成したトピックを選択します。

アラームの名前を設定します。アラーム名は、リージョン内で一意である必要があります。

確認画面に遷移して、問題なければ「アラームの作成」をクリックします。

同様に、「StatusCheckFailed_System」も設定します。

(小ネタ)アラームを作る方法は他にも方法あるぞ

EC2インスタンス管理画面から、「アラームの状態欄」を確認すると「＋」ボタンがあります。

クリックすると、今回作成したアラームを同じように作ることができます。

テスト

「StatusCheckFailed_System」は、AWS側のエラーのため、テストができません。

「StatusCheckFailed_Instance」は、エラーを起こすことができます。

ただし、ネットワークの遮断が発生するためAMIで復元したインスタンスに対してテスト実施してください。

具体的な方法は、以下ブログをご参照ください。

終わりに

今回は、CloudWatchアラームとSNSを使用してEC2インスタンスのステータスチェックの設定を行いました。

復習も兼ねて本ブログを書いてみましたが、今になって疑問が生まれ書いている際に解決することもあり学びも大きかったです。

この記事がどなたかの参考になれば幸いです。以上、AWS事業本部コンサルティング部のたかくに（@takakuni_）でした！